2年間チームの業務改善に取り組んで得た学びを共有します！

2018年7月から先月（2020年6月）までの2年間、所属部署（AWS 事業本部オペレーション部、以降「オペレーションチーム」）の業務改善に取り組んできました。基本的には、業務の効率化や自動化を推進するために必要な作業として下記のような作業を行う役割になります。

• 課題ヒアリング（現状把握）
• 課題管理（優先度付け等）
• 施策の提案および推進（PoC 開発等含む）
• 効果測定など

なお、オペレーションチームでは、クラスメソッドメンバーズという AWS 総合支援のサービスの中でも、24時間365日の技術サポートをお客様（顧客の運用チームの方々）へ提供するサポートエンジニアが（主に）所属する部署となります。 クラスメソッドメンバーズに関するその他詳細等につきましては、下記のページをご参照ください。

この2年間業務改善に取り組んできた中での「気付き」や「学び」など、共有させていただきます。

前提

冒頭に記載のとおり、オペレーションチームは顧客（運用チームの方々）へ技術サポートを提供しているチームとなり、そのチームの運用を改善するということは直接的もしくは間接的に顧客へ価値を提供することができることを意味します。私見となりますが、サービス業において顧客へ提供できる価値は、下記の３つに集約されるものと考えています。

• 価格（提供コスト）
• 速度（提供スピード）
• 品質（サービス品質）

俗に言う「早い、安い、うまい」ですね。

ビジネスを行う上でこの３つを全て兼ね備えた商品やサービスがあれば、（多分）その市場を支配している可能性が高く、通常は何か１つもしくは２つを犠牲にして残りの価値を高める努力をしている商品やサービスが市場では多いものと考えています。オペレーションチームでも「クラスメソッドメンバーズ」というサービスに対する提供価格は決まっているため、品質の高いサービスをより早く提供するために日々努力を続けています。

基本方針

2018年7月から先月（2020年6月）までの2年間、私は KAIZEN Team という専門のチームを立ち上げ業務改善に取り組んできました。このチームの基本的な方針は下記のとおりです。

その１

顧客に対して「直接的」もしくは「間接的」に価値を提供していない作業は、やらない（やめる）

「前提」の章で記載しましたが、我々のミッションは「品質の高いサービスをより早く提供する」が前提にあります。顧客に対して「直接的」もしくは「間接的」に価値を提供していない作業は「必要がない作業」と個人的に考えているため、そのような作業は廃止（やめること）を検討する必要があります。逆に、「直接的」もしくは「間接的」に価値を提供している作業は継続対応が必要かつ業務改善の対象になり得ると考えられます。

その２

「顧客へ提供している価値の度合い」・「作業頻度」・「その作業に必要となる作業量（工数）」を確認する

業務を遂行する上では、様々な作業がありますが作業毎に優先度は異なるはずです。また、実際に業務を改善していく上で改善作業に避ける人的なリソースは有限であるため、各施策に対して優先度付けが必要となることから、優先度を検討するための材料として下記の各項目を確認（計測）した方が良いと思われます。

• 顧客へ提供している価値の度合い
• 作業の発生頻度
• 作業に必要な時間（工数）

例えば、「顧客へ提供している価値の度合い」が同じ２つの作業（A/B）があった場合、どちらの優先度が高いでしょうか？

A. 毎日発生する作業だが、1作業あたり 1分で完了する作業 （1日に1度作業が発生し、1ヶ月の稼働日を 20日と計算した場合、4H/年）

B. 年に 1度の作業であり、1作業あたり 4時間掛かる作業（4H/年）

この場合、頻度や工数の情報だけでは情報が不足し優先度を決めることができません。そのため、サービスが成長（スケール）した際に発生頻度や作業工数等がどのように変化するか？などを事前に予測し暫定的な優先度を考慮する必要があると考えます。このあたりの考え方については、Google の Site Reliability Engineering （SRE） 第5章（トイルの撲滅）の記載が参考になるかもしれません。

その３

Think Big , Start Small , Scale Fast

よく聞く言葉だと思いますが、業務改善に取り組む上で重要なポイントを踏まえて意訳すると下記になります。

1. 完全な自動化を目指す（中途半端な自動化は良くない）
2. 最小要件を定義し小さなプロトタイプ開発から始める（とにかく手を動かす）
3. 運用フェーズも考慮する（要件を満たせるならば、SaaS の利用も検討）

各ポイントについて、１つずつ説明します。

１． 完全な自動化を目指す（中途半端な自動化は良くない）

業務改善に取り組み始めた当初は、私個人の考え方として「一部でも自動化することで業務は改善される」と信じていました。しかしながら、実際に作業の一部のみを自動化する施策の場合、作業者によっては「あまり効果が感じられない」という結果になることがしばしば見られました。推測される理由となりますが、「作業者が業務改善前の作業フローに最適化されてしまっている」等が考えられます。これは業務改善の施策を検討する際の考慮が不足していたという気付きとなり、考えを改める必要がありました。現在私個人の考え方としては、施策検討段階において「（最終的には）完全な自動化を目指す」以外の選択肢は（基本的に）ありません。

２． 最小要件を定義し小さなプロトタイプ開発から始める（とにかく手を動かす）

弊社では「やってみる」という行動原則があり、そこには下記のような説明が記載されています。

「検討に時間を掛け過ぎたり、できない理由を探したり、何もしないことは大きな機会損失です。過去の経験や知識のみを判断基準にせず、好奇心を持って、まずは小さく直ぐにやってみます。より早く始め、より多く失敗し、高速に改善を繰り返すことが私たちの最大の生存戦略です。」

まさに記載の通り、業務改善に取り組む上でこの考え方は非常に重要だと思います。理由は明白かつシンプルで、実際に業務を改善しようとした場合、最低限の機能を有したプロトタイプを実際に業務フローに適用して（利用して）みないと効果が計測できないためです。また、プロトタイプと言えども利用者は動く成果物を見ることができるため、フィードバックが生まれやすい状況となり結果的に改善サイクルを早く回すことができます。

３． 運用フェーズも考慮する（要件を満たせるならば、SaaS の利用も検討）

PoC を経て、プロトタイプ開発に取り組み、実際に業務が改善される効果が測定できれば、本番リリースに向けてテスト等の作業を進めることになると思います。何らかのサービスを開発したとすると、本番リリース後に待っているのは運用フェーズです。せっかく開発したサービスが業務を改善しチームの負担が減ったとしても、運用に負担の掛かるサービスだった場合、負担の掛かる場所が移動しただけで問題が解決されたとは言いがたい状況が生まれてしまいます。そのため、PoC およびプロトタイプ開発を始める際は AWS フルマネージド型のサービス利用を前提にアーキテクチャを選定し、これまでサービス開発を進めてきました。

AWS フルマネージド型のサービス（API Gateway,Lambda,DynamoDB など）の良いところは、小さく始めることができ、標準構成で（ほぼ）冗長化されておりかつスケーラブルで運用部分を AWS にオフロードできることです。

これは、業務改善を行う上で必要不可欠なサービスだと考えています。なお、外部の SaaS サービスが自分たちの求める要件にマッチすれば、開発コストおよび運用コストを SaaS 利用料にオフロードできるため、施策検討段階ではそのあたりも含めて検討した方がトータルコストとして安く済むケースもあるかと思います。

その他の学んだこと

業務改善の施策やアイデア等は１箇所にまとめ、Issue ベースで議論すること

弊社での社内コミュニケーションは、Slack（以前は、Chatwork）等のチャットベースが基本となります。チャット・コミュニケーションは慣れてくると気軽で手放せないツールではあるのですが、デメリットとしてコンテキストが分散しがちという問題も発生しやすいと感じます。コンテキストが分散してしまうと、後で経緯を追いかけるのが難しいため、Issue ベースで議論する or 経緯を後で追いかけることができるよう Issue に対して議論した際のコミュニケーションへのリンク（URL）を記録するなどの工夫が必要です。

定期的（何ヶ月ごと）に施策成果などをまとめ、チーム内で振り返りミーティングを実施すること

業務改善に終わりはありません。世の中の状況は日々変化しています。社会や会社のみならず、人や物事の考え方が変われば業務の進め方もまた日々変化することが常かと思います。それだけでなく、何か問題を解決するとこれまでに無かった課題が生まれてくることもあるかと思います。業務改善に取り組む際の課題が中長期的な施策であれば、施策開始タイミングと今現在の課題認識にズレが無いかを見直したり、定期的に課題や施策等を棚卸しして整理するタイミングを設けた方が良いかもしれません。私のチームでは、3ヶ月間隔で「対応した施策」と「次の3ヶ月で対応する予定の施策」をベースにチーム内で振り返りのミーティング（意識合わせや雑談）をしてきました。チームメンバー間で認識を合わせるタイミングとしては、コレくらいの頻度が感覚的に良さそうだなという個人的な印象です。

さいごに

これまでの２年間を個人的に振り返り、取り組んできた改善活動の中で感じた所感等をふわっと紹介させていただきました。 読者の方々の実業務にマッチしないナレッジかもしれませんが、同様に業務改善に取り組んでおられる、どこかの誰かの参考情報となれば幸いです。

ではでは